Conversation
…pport and conditional routing
…d make getInitialFormData case-insensitive
…nd HouseholdCircumstances CCD interface
…nd regular-income steps
… upload-docs based on CCD data
145bad1 to
5d07c1c
Compare
| const possessionClaimResponse: PossessionClaimResponse = { | ||
| defendantResponses: { | ||
| householdCircumstances: { | ||
| shareIncomeExpenseDetails: toYesNoEnum(provideFinanceDetails), |
There was a problem hiding this comment.
This field uses backend YesOrNo not VerticalYesNo type, so can we send canonical values ("Yes" / "No") instead of "YES" / "NO" for consistency with the API contract?
src/main/steps/utils/yesNoEnum.ts
Outdated
| * toYesNoEnum('NO') // returns 'NO' | ||
| */ | ||
| export function toYesNoEnum(value: 'yes' | 'no'): YesNoValue { | ||
| return value.toLowerCase() === 'yes' ? 'YES' : 'NO'; |
There was a problem hiding this comment.
Could we align the frontend type for this field to match backend YesOrNo values ("Yes" / "No"), so payload and types stay in sync? We could use separate converters for different enum families (YesOrNo vs VerticalYesNo) to avoid mixing formats across steps
| * fromYesNoEnum('NO') // returns 'no' | ||
| * fromYesNoEnum(null) // returns undefined | ||
| */ | ||
| export function fromYesNoEnum(value: YesNoValue | string | undefined): 'yes' | 'no' | undefined { |
There was a problem hiding this comment.
fromYesNoEnum currently accepts many casings, which is useful, but can we keep to... output canonical ("Yes" / "No") so writes are consistent?
| } | ||
|
|
||
| export interface HouseholdCircumstances { | ||
| shareIncomeExpenseDetails?: YesNoValue; |
There was a problem hiding this comment.
These HouseHoldCirumstances fields should match the backend entity/domain and match the "Yes"/"No" values. I've changed this on my PR already here
|
Few comments left to address, also would be good to have the details of all the changes introduced in the PR description along with screenshots of all screens introduced |
Jira link
https://tools.hmcts.net/jira/browse/HDPI-3764
Change description
Testing done
Security Vulnerability Assessment
CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?
Checklist